1. Queue Limitations and Constraints
Even though the Queue
service provides a scalable and highly available infrastructure for
asynchronous message communications in the cloud, it has some
limitations and constraints that are important to understand before
diving deep into architecture and programming. The limitations of the
Queue service are as follows:
The Queue service
supports an unlimited number of messages, but individual messages in
the Queue service can't be more than 8KB in size.
The FIFO behavior of the messages sent to the Queue service isn't guaranteed.
Messages can be received in any order.
The Queue service doesn't offer guaranteed-once delivery. This means a message may be received more than once.
Messages
sent to the Queue service can be in either text or binary format, but
received messages are always in the Base64 encoded format.
The
expiration time for messages stored in the Queue service is seven days.
After seven days, the messages are garbage-collected.
2. Queue Service Architecture
The Queue service architecture consists of a three-level hierarchy: accounts, queues, and messages, as shown in Figure 1.
Your Windows Azure storage account is the entry point to the Queue service via the REST API.
2.1. Windows Azure Storage Account
A Windows Azure
storage account encompasses the Blob, Queue, and Table services. The
URI scheme for accessing the Queue service via your storage account is
<http|https>://<account name>.queue.core.windows.net
where <account name> is the unique name you created for your storage account. The <account name> must be globally unique.
For example, the Queue service for the storage account that I created in the previous chapter can be referenced as
<http|https>://proazurestorage.queue.core.windows.net
2.2. Queues
A queue
is a logical destination for sending messages. There can be any number
of queues in an account in the Queue service. A queue stores messages
and makes them available to applications via the REST API. Queues can
have metadata in the form of name-value pairs up to 8KB in size per
queue. The Queue service support only private access; that means you
need to have account privileges in order to access queues in a Queue
service.
You can access a queue using the URI
<http|https>://<account name>.queue.core.windows.net/<queue name>
where <queue name> is the name of the queue you want to access.
For example, if you create a queue named logsqueue in the proazurestorage account, you can reference it using the following URI:
<http|https>://proazurestorage.queue.core.windows.net/logsqueue
The naming constraints for a queue are as follows:
The queue name must be a valid DNS name.
Queue names must be unique within an account.
Queue names must start with a letter or a number.
Container names can't contain any special characters other than the dash (-) character.
The dash (-) character must be immediately followed by a character or a number.
All the characters in the queue name must be lowercase.
Queue names can't be less than 3 or more than 63 characters in length.
If a queue name or the URI violates the naming convention, an HTTP status code 400 (Bad Request) is returned by the server.
2.3. Messages
Messages are stored in
queues. There is no limit to the number of messages that can be stored
in a queue, but the size of each individual message can't exceed 8KB.
To communicate large object messages, you can put the large object in a
blob and then send the URI of that object as a message to a queue.
When you send a message, it
can be in either text or binary format; but when you receive a message
from the queue, it's always in Base64-encoded format. A GUID MessageID
assigned by the Queue service uniquely identifies a message in the
queue.
A message has the following attributes:
MessageID: Uniquely identifies a message in a queue and is created by the Queue service when you send the message to the Queue service.
PopReceipt: –An attribute of the message used for deleting or popping the message out from the queue.
Visibilitytimeout:
An integer value representing the visibility of the message in seconds
after it's received by a receiving application. The default
visibilitytimeout value is 30 seconds, which means that after a message
is received, it remains invisible to other applications for 30 seconds
(unless it's deleted by the receiving application). The maximum
visibilitytimeout value is 2 hours. The visibilitytimeout value is
passed to the Queue service while a message is being retrieved from a
queue.
Messagettl:
An integer value representing the time-to-live value in seconds. When
you send a message to a queue, you can specify the messagettl, which
instructs the Queue service to keep the message only for the specified
number of seconds. The default value for messagettl is 7 days. That
means if you don't specify a messagettl value, the Queue service keeps
the message for 7 days before it's garbage-collected.
You can access messages in a queue using the following URI
<http|https>://<account name>.queue.core.windows.net/<queue name>/messages
where <queue name>
is the unique name of the queue within the scope of the account
specified in the URI, and messages is a constant string representing
all the messages in the specified queue. For example, if you create a
queue named logsqueue, you can get messages from it by calling the
following URI:
<http|https>://proazurestorage.queue.core.windows.net/logsqueue/messages
